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The ’go’ URI Scheme for the Common Name Resolution Protocol 
Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2002). All Rights Reserved. 
Abstract 


This document defines a URI scheme, ’go:’ to be used with the Common 
Name Resolution Protocol. Specifically it lays out the syntactic 
components and how those components are used by URI Resolution to 
find the available transports for a CNRP service. Care should be 
taken with several of the URI components because, while they may look 
like components found in other URI schemes, they often do not act 
like them. The "go" scheme has more in common with the location 
independent "news" scheme than any other URI scheme. 
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The two goals of the CNRP [3] URI [1] are to identify both a specific 
common-name record at a specific server and to identify a possibly 


dynamic query or entry point into the query process. 
requires that the ID be a core query term, 


Since CNRP 
these two cases can be 


generalized down to simply specifying a query that contains only the 


ID of 


On first glance it would seem a simple enough exercise to 


the item. 


canonicalize the XML encoded query and then insert it into the query 
portion of the URL. The problem here is that, 
any remotely complex query will quickly blow out the URI 


rules, 


length limitations. 


due to the encoding 


The suggested solution is to provide a 


simplified query syntax that is a subset of what is available via the 


XML. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", 


document are to be interpreted as described in RFC 2119 
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Syntax Rules 


The CNRP URI comes in two forms. 
specific server. 
meant to be sent to several different CNRP services. 
two examples are for pedagogical purposes only. 


Syntax 
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The first form is for talking to a 


The second form is for expressing a query that is 


The following 
The complete ABNF 


grammar in Section 3.2 is the only authoritative syntax definition. 


go://[<host>] ? [<common-name>] * [;<attribute>=[<type>, ]<value>] 


and 


go:<common-name>* [;<attribute>=[<type>, ]<value>] 


3.2 ABNF Grammar 


The full ABNF 


2396 [1]): 


cnrp-uri 
forml 
form2 


id-req 
avpair 


server 
common-name 


attribute 
value 


type 
unreserved 


escaped 
hex 
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[2] 


(certain values are included by reference from RFC 
"go:" (forml / form2) 
"//" [server] ["?" ((common-name *avpair) / id-req) ] 

= common-name *avpair 
"id=" value 
";" attribute "=" [ type "," ] value 
// as specified in RFC2396 
= * (unreserved | escaped) 
= * (unreserved | escaped) 
= * (unreserved | escaped) 
= * (unreserved | escaped) 
= // as specified in RFC2396 
"S" hex hex 
"o" | "q" | wow | wu | wan | won | wen | won | 
ngu won wan "p" "non "D" | "p" | "pr | 
" a " " b " " c " " d " " e " " E " 
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3.3 Special Cases and Default Values 

3.3.1 If There is Only a Server 
In the case where the CNRP URI contains only the server production 
then the URI identifies a given CNRP server, not any particular query 
that is to be done. A client can assume that this server will at 
least answer the ’servicequery’ request. 


3.3.2 If Server is Empty Then server=localhost 


If the ’server’ element has no value then its value MUST be assumed 
to be "localhost". 


3.3.3 Default Port 


CNRP’s well known HTTP transport port is 1096. If the port value 
portion of the server production is not specified then port 1096 
SHOULD be used if the client has no prior knowledge about other ports 
or transports that the service may support. 


3.4 Encoding Rules 


The common-name, query parameters, and parameter values must be 
encoded using the UTF-8 encoding scheme [5], and any octet that is 
not one of the permitted characters per the above grammar MUST 
instead be represented by a "%S" followed by two characters from the 
<hex> character set above. The two characters give the hexadecimal 
representation of that octet. 


4. Transport Independence 


As stated in the CNRP protocol specification [3], CNRP is allowed to 
be expressed over multiple transport protocols with HTTP being 
mandatory to implement. In the case where a client attempts to 
resolve a CNRP URI and it knows nothing about the service being 
referenced in that URI, then it SHOULD use HTTP on the CNRP default 
port (1096). 


5. Examples 


go:Mercedes%20Benz 
This example shows a general query for the common-name "Mercedes 
Benz". The intent is that the query should be packaged with any 
client provided defaults and sent to the one or more services that 
the client has configured to ask. 
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go://?Mercedes%20Benz 
This example shows a general query for the common-name "Mercedes 
Benz" that is sent to the server running on the ’localhost’. 


go://cnrp.foo.com?Mercedes%20Benz; geography=US-ga 
This example shows a query for the common-name "Mercedes Benz" in 
the geographic area "US-ga" which should be sent to the server 
found at cnrp.foo.com. 


go://cnrp.foo.org?Martin%20J.%20DSC3%BCrst 
This example includes a UTF-8 character encoded using hex 
escaping. The value encoded is a u-umlaut (a ’u’ with two dots 
over it). This simple query is sent to a server found at 
cnrp.foo.org with no parameters. 


go://cnrp.foo.com?id=5432345 
Here only an id is given which means that his example points 
directly at a particular common-name record on a particular 
server. This example would probably be found in a link on a web 
page of some type. 


6. Security Considerations 


In addition to the security considerations inherent in CNRP itself 
(see the Security Considerations section of RFC 3367 [3]), the URI 
mechanism can also be used to retrieve a URI identifying some other 
site by including just the ID and not the common-name being linked 
to. I.e., the user may think he/she is being shown the URI currently 
mapped to the "BMW" common-name but in the case where only the ID is 
used the actual common-name is not part of the URI, thus making it 
possible to use a CNRP URI without knowing which common-name it is 
referring to. 


7. IANA Considerations 


The IANA is asked to register the URL registration template found in 
Appendix A in accordance with RFC 2717 [6]. 
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Appendix A. Registration Template 
URL scheme name: go 
URL scheme syntax: Section 3.2 
Character encoding considerations: Section 3.4 
Intended usage: Section 1 
Applications and/or protocols which use this scheme: [3] 
Interoperability considerations: None not specified in [3] 
Security considerations: Section 6 
Relevant publications: [3] 
Contact: CNRP Working Group 
Author/Change Controller: IESG 
Author’s Address 
Michael Mealling 
VeriSign, Inc. 
21345 Ridgetop Circle 
Dulles, VA 20170 


US 


Phone: (703) 742-0400 
EMail: michael@verisignlabs.com 
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Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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